home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / XMODEM.ZIP / xmodem.txt next >
Text File  |  1996-03-06  |  4KB  |  103 lines
  1. Perception presents:
  2. ------------ Understanding The X-Modem File Transfer Protocol ---------------
  3.  
  4.                   by Em Decay
  5.  
  6. This has to be one of the most internationally accepted protocols for upload-
  7.  ing and downloading binary and text files.  It is fairly straight-forward as
  8.  to how it is set up and there are some error checking capablities.
  9.  
  10.  
  11. --- Before you begin ---
  12.  
  13. Things you need to know beforehand...
  14.  
  15. The following terms are simply ascii codes:
  16.     SOH = chr(1)  = CTRL-A =
  17.     EOT = chr(4)  = CTRL-D = End of Transmission
  18.     ACK = chr(6)  = CTRL-F = Positive Acknowledgement
  19.     NAK = chr(21) = CTRL-U = Negative Acknowledgement
  20.     CAN = chr(24) = CTRL-X = Cancel
  21.  
  22. In order to send the file, you must first divide it into 128 byte sections
  23.  (packets).  Bytes 0-127 of the file make up the first packet, bytes 128-255
  24.  make up the second packet, etc.
  25.  
  26. The packet number sent is simply the number of the packet.  If the packet
  27.  number is greater than 255, then subtract 256 repeatly until the number is
  28.  between 0 and 255.  For example, if you were sending packet 731, then you
  29.  would send 731 - 256 - 256 = 219.
  30.  
  31. The 1's complement of a byte (to make life easy) is simply 255 minus the
  32.  byte.  For example, if you had to take the 1's complement of 142, the answer
  33.  would be 255 - 142 = 133.
  34.  
  35. The checksum is the value of all the bytes in the packet added together.  For
  36.  example, if the first five bytes were 45, 12, 64, 236, 173 and the other 123
  37.  bytes were zeroes, the checksum would be 45+12+64+236+173+0+0+...+0 = 530.
  38.  However, to make each block one byte smaller, they repeatly subtract 256
  39.  from the checksum until it is between 0 and 255.  In this case, the checksum
  40.  would be 530 - 256 - 256 = 18.
  41.  
  42. The first byte the downloader sends is referred to as the NCGbyte.
  43.  
  44. Provided that you aren't lost already, here is what happens next.  The steps
  45.  below describe who sends what when :)
  46.  
  47.  
  48. --- The Actual Transfer ---
  49.  
  50. The uploader waits until the downloader sends a NAK byte.  The NAK byte
  51.  is the signal that the downloader is ready to start.  This byte is referred
  52.  to as the NCGbyte.  If the downloader takes too long or an error occurs then 
  53.  the uploader will stop waiting or "Time Out".  If this happens, then the 
  54.  file transfer must restart.
  55.  
  56. With each packet sent...
  57.  
  58.     The uploader sends:
  59.  
  60.     1. an SOH byte                             {1 byte}
  61.     2. the packet number                       {1 byte}
  62.     3. the 1's complement of the packet number {1 byte}
  63.     4. the packet                            {128 bytes}
  64.     5. the checksum                            {1 byte}
  65.     The above five things are called the block.
  66.  
  67.     The downloader:
  68.  
  69.     1. ensures that the packet number sent matches the actual packet number
  70.      that it is (If the third block send has a '4' as the second byte,
  71.      something is wrong --> CANCEL TRANSFER (send CAN byte))
  72.     2. adds the packet number and the 1's complement of it together to make
  73.      sure that they add up to 255.  if they don't --> CANCEL TRANSFER
  74.     3. adds up all the bytes in the packet together --> THE SUM
  75.     4. compares the last two significant digits of THE SUM with the checksum
  76.     5. if everything looks ok (sum=checksum), then the downloader appends the
  77.      bytes in the packet to the file being created (sent).  The down-
  78.      loader then sends an ACK byte which tells the uploader to send the
  79.      next block.
  80.        if the sums do not match then the downloader sends an NAK byte which
  81.      tells the uploader to send the same block it just sent over again.
  82.  
  83. When the uploader sends an EOT byte instead of an SOH byte, the downloader
  84.  sends a NAK byte.  If the uploader sends another EOT immediately after that,
  85.  the downloader sends an ACK byte and the transfer is complete.
  86.  
  87. Another thing, the downloader can cancel the transfer at any time by sending
  88.  a CAN byte.  The uploader can only cancel between blocks by sending a CAN
  89.  byte.  It is recommended that you send anywhere between 2 and 8 consecutive
  90.  CAN bytes when you wish to cancel as some programs will not let you abort if
  91.  only 1 CAN byte is sent.
  92.  
  93.  
  94. --- Wrap Up ---
  95.  
  96. Hopefully, you were able to follow along. :)  If not, you can e-mail me at
  97.  em_decay@norlink.net  and I will try to clarify it for you.  Have fun :)
  98.  
  99. Perception:    Em Decay -- Mark Korhonen
  100.            Cmf ------- Chris Fillion
  101.  
  102. Written on Dec.28/95
  103.